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REMARKS 

Claims 1-9 and 25-33 are pending in this application. 

Applicants wish to thank the Examiner for withdrawing the obviousness-type double 
patenting rejection from the last Office Action. 

Applicants respectfully submit that the remaining rejections should also be withdrawn 
for the following reasons. 

L Claims 1, 2, 9, 25, 26 and 33 

The Office Action continues to reject claims 1, 2, 9, 25, 26 and 33 under 35 U.S.C. § 
103(a) as being impatentable over the article by Bhattacharya et al. ("Bhattacharya") in view 
of U.S. Patent No. 6,785,690 ("Davidson"). The issue with respect to these claims is easy to 
frame: 

1) Independent claims 1 and 25 recite "storing the data in ... at least one 
designated field of [a] plurality of fields of [an] instance of [a] user defined type as a 
file outside of [a] database store" while "storing the data in each of the other fields of 
said plurality of fields of the instance of the user defined type within the database 
store." 

2) The Examiner asserts that Davidson teaches that an instance of a user-defined 
type having a plurality of fields can be persisted in a database store; 

3) Bhattacharya describes the "DB2/DataLinks" product available from IBM 
which, as recognized in the Backgroimd section of the instant application, provides 
the ability to link a column entry in a database table to a file in a file system by 
storing a reference {e.g., URL) to the file in the column entry of the table\ and 

4) The Examiner asserts, but applicants disagree, that combining Bhattacharya 
with Davidson to arrive at the claimed invention would have been obvious to one of 
ordinary skill in art. 

Applicants submit that the asserted combination is improper because (i) merely combining 
the teachings of these references does not produce the claimed invention, and (ii) the 
Examiner still has not provided sufficient evidence of a motivation to combine the references 
in a manner that would produce the claimed invention. 
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A. Merely Combining Bhattacharya And Davidson Does Not Result 
In The Claimed Invention 

All that Bhattacharya describes is linking a column entry in a database table to a file 
in a file system by storing a reference {e.g,, URL) to the file in the column entry of the table. 
A database table is not an instance of a "user-defined type," nor is a column entry of such a 
table a "field" of a user-defined type. Consequently, merely combining Davidson with 
Bhattacharya would not produce the claimed invention. All that would result fi*om such a 
combination is a system in which an instance of a user-defined type having a plurality of 
fields can be persisted in a database (as taught by Davidson), and in which column entries in 
a database table can be linked to a file in a file system by storing a reference (e.g., URL) to 
the file in the column entry of the table (as taught by Bhattacharya). That does not result in 
the claimed invention. Rather, to arrive at the claimed invention, one would have to modify 
the basic notion of a user-defined type as described in Davidson, by adding the claimed 
ability to store the data in a designated field of an instance of a user defined type as a file 
outside of the database store, while storing the data in each of the other fields of the instance 
within the database store. That is not an insignificant modification. Applicants respectfiiUy 
submit that there is nothing in either reference, nor in the general knowledge of one skilled in 
the art, that would have motivated a skilled artisan to make such a significant modification. 

B. There Is No Motivation To Combine Davidson and Bhattacharya 
In A Manner That Would Produce The Claimed Invention 

Li response to applicants' prior assertion that the Examiner has not provided sufficient 
evidence of a motivation to combine the references, the Examiner now asserts that "[t]he 
motivation to combine Davidson with Bhattacharya is that the user-defined data type are safe 
and secured because they are stored externally fi-om the database," and that "in case of 
disaster or system failure, these data can easily be retrieved firom the external data store." 
Applicants respectfiiUy disagree. 

A desire for data protection would not motivate someone to implement the claimed 
invention. If data protection were desired, that desire would extend to all of the fields of an 
instance of a user-defined type. However, with the claimed invention, only some of the fields 
of an instance of a user-defined type are stored outside of the database store, while the other 
fields of that same instance are stored within the database store. Storing only some of the 
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fields of a user-defined type outside of the database store would not fully address any desire 
for data protection. Indeed, in the Abstract of the Bhattacharya article, the author points out 
that "[mjanaging a combined store consisting of database data and file data ... is a challenge''' 
and that "backup/recovery and data consistency" are "two potentially problematic aspects of 
such a data management system." Thus, as Bhattacharya recognizes, a desire for data 
protection would not be a motivation for combining Davidson and Bhattacharya to produce 
the claimed invention, but instead is a problem to address. 

The Examiner has not identified any statement or discussion in either of the cited 
references or elsewhere that would have motivated one of ordinary skill to modify the basic 
notion of a user-defined type, as described in Davidson, to add the claimed ability to store the 
data in at least one designated field of an instance of a user defined type as a file outside of 
the database store, while storing the data in each of the other fields within the database store. 
Davidson certainly does not recognize a need for such a capability, and neither does 
Bhattacharya, Bhattacharya deals with database tables and column entries, not user-defined 
types. 

Applicants respectfully submit that the Examiner has not provided any evidence from 
the references themselves or otherwise that would provide the required motivation to 
combine. >And as explained above, the Examiner's assertion that a desire for data protection 
would provide such motivation is incorrect. Because there is no evidence of record that one 
of ordinary skill in the art would have been motivated to make the asserted combination, that 
combination cannot serve as the basis for a rejection under Section 103(a). 

For all the foregoing reasons, therefore, applicants respectfully request that the 
Section 103(a) rejection of claims 1, 2, 9, 25, 26 and 33 be withdrawn. 

II. Claims 3-8 and 27-32 

Claims 3-8 and 27-32 stand rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Bhattacharya and Davidson and further in view of U.S. Patent 6,070,174 ("Starek"). 
Inasmuch as these claims depend, either directly or indirectly, fi-om one of independent 
claims 1 and 25, applicants submit that they are patentable for the same reasons as presented 
above with respect to those independent claims. Nevertheless, with respect to many of these 
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dependent claims, applicants submit that the rejections are improper for the following 
additional reasons. 

A. Claims 3 and 27 

Claims 3 and 27 recite that the data of the fields of the object that are stored within 
the database store are stored as fragments within a column of a database table that has been 
designated as having the user defined type. The Office Action asserts that Starek teaches this 
feature at column 10, lines 29-51. Applicants do not understand how. That portion of Starek 
describes a "master file table" of an operating system that stores "file records" for the files 
stored in the operating system's file system. Claims 3 and 27 have nothing to do with files or 
file systems. Consequently, Applicants do not understand how combining this aspect of 
Starek with Davidson and Bhattacharya would produce the invention recited in claims 3 and 
27. Moreover, because claims 3 and 27 have nothing to do with files or file systems, the 
discussion in the Office Action of a "motivation" for combining Starek with Davidson and 
Bhattacharya, which focuses on file system features, does not make sense. Reconsideration 
of the rejection of claims 3 and 27 is respectfully requested for these additional reasons. 

B. Claims 4 and 28 

Claims 4 and 28 recite that "a unique identifier associated with the object" is stored 
"in another column of the table in a same row as the data of the fields of the object." The 
Office Action asserts that this feature is taught by Bhattacharya' s description of a 
^^RecoveryID_at_lmk'' identifier. The RecoveryID_at_link identifier is described as a "time 
based recovery identifier." But there is no indication in Bhattacharya that this identifier is 
associated with an object, i.e., an instance of a user defined type, that has been stored in a 
colimm of a database table, as claimed by applicants. Applicants respectfully submit, 
therefore, that Bhattacharya does not teach the claimed identifier. For that reason alone, the 
rejection of these claims should be withdrawn. 

Moreover, to the extent that this rejection again requires the combination of multiple 
references, the Examiner is required to state a motivation for combining the 
RecoverylDjat link feature of Bhattacharya with the other references. In this case, the 
Examiner has provided no evidence of any motivation whatsoever. Consequently, the 
rejection is improper and must be withdrawn. 
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C. Claims 5 and 29 

Claims 5 and 29 recite that the data in the designated field of the object that is stored 

outside of the database "is stored as a file within a predetermined directory of a file system of 

a computer on which the database server is executing." The Office Action asserts that this 

feature is taught by Starek at column 10, lines 14-18. That portion of Starek states: 

An NTFS volume, however, stores all file system data, such as 
bitmaps and directories, and even the system bootstrap, as 
ordinary files. NTFS is like the FAT file system in that it uses 
the cluster as its fimdamental unit of disk allocation. 

Applicants do not understand how this portion of Starek teaches the claimed feature. Nothing 

in the cited portion of Starek has anything to do with user-defined types, let alone storing a 

designated field of an instance of a user-defined type outside of a database store as a file 

"within a predetermined directory of a file system." Moreover, the Examiner has again failed 

to provide any evidence of a motivation to combine this aspect of Starek with the claimed 

invention. For these reasons, the rejection is improper and should be withdrawn. 

D. Claims 7 and 31 

Claims 7 and 31, which depend firom claims 6 and 30, respectively, recite the steps 
that are performed when an application requests access, via the file system of a computer, to 
the file in which the data of a designated field of a user-defined type is stored outside the 
database store. In particular, while access is made via the file system, these claims recite that 
the request for access to the file identifies the file not by its identity within the file system, 
but by identifying "the field of the object [for which the file holds data] . . . within the 
database store and then "determining fi-om the identity of the field of the object within the 
database store a path within the file system of the computer to the file containing the data of 
that field of the object." The Office Action asserts that Starek teaches these claimed steps at 
column 7, lines 9-20 and column 4, lines 23-32. But none of these portions of Starek 
describe accessing a file via a file system, where the file is identified not by its identity in the 
file system, but rather by identifying the field of an object within a database store for which 
the file holds data. Because Starek does not teach the claimed feature, the rejection should be 
withdrawn. 

• Moreover, to the extent that this rejection again requires the combination of multiple 
references, the Examiner has again failed to provide any evidence of a motivation to make 
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the asserted combination. For this additional reason, the rejection is improper and must be 
withdrawn. 

For all the foregoing reasons, applicants respectfully request that the Section 103(a) 
rejections of claims 3-8 and 27-32 be withdrawn. With respect to claims 4, 5, 7, 28, 29 and 
3 1 in particular, the failure of the Examiner to provide evidence of a motivation for the 
asserted combinations renders those rejections improper. If the Examiner believes that a 
motivation to combine exists, then applicants submit that the Examiner should 
withdraw the finality of the present Office Action and provide the applicants with an 
opportunity to respond to any asserted motivation to combine. 

CONCLUSION 

For the foregoing reasons, applicants respectfully submit that all of the claims 
patentably define over the cited art of record, and therefore, that the instant application is in 
condition for allowance. Reconsideration of the May 30, 2006 Office Action and an early 
Notice of Allowance are earnestly solicited. 



Respectfully submitted. 



Date: July 31, 2006 
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